feat: Support an existing Secret in the Helm chart - #391

Summary

templates/secrets.yaml always renders <fullname>-secrets from values (internalServiceAuth.token, egressGrant.secret, executionManifest.privateKey, and the Redis and MinIO credentials).

Anyone who keeps values in Git, or renders the chart with helm template for CI tooling, ends up committing those secrets or patching the rendered output.

This adds an existingSecret value, empty by default. When it's set:

• secrets.yaml renders nothing.

• Every secretKeyRef points at the given Secret, through a new codeapi.secretName helper.

• The executionManifest.privateKey check is skipped, as the key lives in the Secret.

• If executionManifest.publicKey is empty, sandbox-runner reads SANDBOX_EXECUTION_MANIFEST_PUBLIC_KEY from the Secret's codeapi-execution-manifest-public-key key.

  The public key isn't secret, but it seemed cleaner to keep both halves of the key together in the Secret, but setting executionManifest.publicKey still takes precedence.

The bundled Redis already supports redis.auth.existingSecret, so this adds feature parity to the parent chart.

Also I added a new "Using an existing Secret" section in the README.

Testing

I checked that we remain backwards compatible for people who don't need this feature:

• Without existingSecret, the rendered output is byte-for-byte identical to main for values-local.yaml, for the defaults with a keypair set, and for external Redis with S3 and IRSA and a fullnameOverride.

• With existingSecret=my-secret, no Secret is rendered by this chart (only the MinIO subchart's own), all 15 secretKeyRefs point at my-secret, and sandbox-runner reads the public key from it.

  With executionManifest.publicKey also set, the literal value is used.

• Without existingSecret or the keypair, the install still fails with the existing error messages.

• helm lint passes.